For the love of metadata? : a functional approach to describing scholarly works

dcterms:abstract) Publisher (dc:publisher) Identifier (dc:identifier) Is Available As (eprint:isAvailableAs) Creator (dc:creator) Description of a Copy of a Manifestation of an Expression of the eprint Funder (marcrel:FND) Entity Type (dc:type) Grant Number (eprint:grantNumber) Access Rights (dcterms:accessRights) Supervisor (marcrel:THS) Licence (dcterms:licence) Affiliated Institution (eprint:affiliatedInstitution) Date Available (dcterms:dateAvailable) Has Adaptation (eprint:hasAdaptation) Is Part Of (dcterms:isPartOf) Is Expressed As (eprint:isExpressedAs) Description of an Agent Description of an Expression of the eprint Entity Type (dc:type) Entity Type (dc:type) Name (foaf:name) Title (dc:title) Family Name (foaf:family_name) Description (dc:description) Given Name (foaf:givenname) Identifier (dc:identifier) Workplace Homepage (foaf:workplaceHomepage) Date Available (dcterms:dateAvailable) Mailbox (foaf:mbox) Status (eprint:status) Homepage (foaf:homepage) Version Number or String (eprint:version) Language (dc:language) Type (dc:type) Copyright Holder (eprint:copyrightHolder) Has Version (dcterms:hasVersion) Has Translation (eprint:hasTranslation) Bibliographic Citation (dcterms:bibliographicCitation) References (dcterms:references) Editor (marcrel:EDT) Is Manifested As (eprint:isManifestedAs) Figure 2 : the application profile metadata properties The application profile lists the metadata properties, including mandatory elements, for each entity, provides usage guidelines and offers illustrative examples. Note that for this application profile, we have made very few elements mandatory. The profile makes use of properties from both the DC Metadata Element Set (simple DC) [3] and DC Metadata Terms (includes qualified DC terms) [11]. In addition, the MARC relator codes [12] and the Friends of a Friend (FOAF) Scheme [13] introduce additional properties; only five new properties have been created from scratch: grant number, affiliated institution, status, version and copyright holder. Figure 2 lists the metadata properties for each entity. Where existing dc:relation qualifiers have been used (is part of, has version), the relationships being documented have been clearly defined alongside five new properties: •has adaptation •has translation •is expressed as •is manifested as •is available as Vocabulary Encoding Schemes facilitate the creation of consistent metadata and can help fulfil a number of the functional requirements. For this application profile, four vocabularies have been defined for: •access rights (Open, Restricted or Closed) •entity type (ScholarlyWork, Expression, Manifestation, Copy or Agent) •status (Peer Reviewed or Non Peer Reviewed) •resource type (see figure 3) Figure 3: the eprints type vocabulary The futureThe application profile isn't a blueprint for repository design, rather it offers a mechanismfor exchanging and exposing metadata records that can support the functionalrequirements outlined above. To facilitate this, an XML format known as Eprints DC XML[13] has been provided. This format is based very closely on the latest draft encodingguidelines for XML and RDF/XML being considered by the DCMI Architecture Community[14]. For existing repositories wishing to work with the profile, they may find that theyalready capture much of the richness specified here, but at the moment are unable toshare this over OAI-PMH due to the limitations of simple Dublin Core. New repositoriescan use the application profile as a guide for making decisions about what metadataformat to use, in conjunction with their local requirements. The application profile makesno statements about how a repository should create and store its metadata, nor aboutwhere information is drawn from. Increasingly repositories will be able to draw data fromexisting systems or use automatic generation tools, making the metadata process asefficient and authoritative as possible.For this application profile to be useful, it must be validated, disseminated and discussedby the community. It also needs to be implemented in repositories and eprints dc xmlmade available for use by aggregators offering added-value services. Developers fromthe main repository software platforms, EPrints, DSpace and Fedora , have all indicated awillingness to work with the application profile and discussions within the community haveindicated that there is interest and support for embedding the profile into the repositoryrealm. References1.Eprints Application Profile http://www.ukoln.ac.uk/repositories/digirep/index/Eprints_Application_Profile2.Intute Repository Search Project http://www.intute.ac.uk/projects.html3.Eprints Application Profile Functional requirements specification http://www.ukoln.ac.uk/repositories/digirep/index/Functional_Requirements4.Dublin Core Metadata Element Set, Version 1.1. DCMI Recommendation. April 2006.http://dublincore.org/documents/dces/5.Lagoze, Carl, Van de Sompel, Herbert, Nelson, Michael and Warner, Simeon. The Open ArchivesInitiative Protocol for Metadata Harvesting. Protocol Version 2.0 of 2002-06-14.http://www.openarchives.org/OAI/2.0/openarchivesprotocol.htm6.IFLA, Functional Requirements for Bibliographic Records, 1998 http://www.ifla.org/VII/s13/frbr/frbr.pdf7.Eprints Application Model http://www.ukoln.ac.uk/repositories/digirep/index/Model Powell, Andy,Nilsson, Mikael, Naeve, Ambjörn and Johnston, Pete, DCMI Abstract Model. DCMI Recommendation,May 2005 http://dublincore.org/documents/abstract-model/8.Eprints Application Profile http://www.ukoln.ac.uk/repositories/digirep/index/EPrints_Application_Profile9.Johnston, Pete and Powell, Andy. Expressing Dublin Core metadata using XML. DCMI Working Draft.May 2006.http://dublincore.org/documents/2006/05/29/dc-xml/10.DCMI Usage Board, DCMI Metadata Terms, DCMI Recommendation, December 2006http://dublincore.org/documents/dcmi-terms/11.Library of Congress Network Development and MARC Standards Office, MARC Code Lists forRelators, Sources, Description Conventions, January 2007 http://www.loc.gov/marc/relators/12.Brickley, Dan and Miller, Libby, FOAF Vocabulary Specification, January 2006http://xmlns.com/foaf/0.1/13.Johnston, Pete. Eprints DC XML. November 2006.http://www.ukoln.ac.uk/repositories/digirep/index/Eprints_DC_XML14.DCMI Architecture Community. http://dublincore.org/groups/architecture/